1. Field of the Invention
The present invention relates to the field of network management technologies. In particular, the present invention relates to increasing the numbers of end-hosts that can participate in a standby router protocol.
2. Background Information and Description of Related Art
The use of standby routers in an Internet Protocol (IP) network is known in the art. The Internet Engineering Task Force (IETF) has published a draft standard protocol for using standby routers, also referred to as redundant routers, entitled Virtual Router Redundancy Protocol, version 2-05, on Jan. 5, 2000 (VRRP).
In a typical network configuration, end-hosts that are connected to a layer-2 domain communicate with other subnets through the use of a default router. Often, the default router is statically configured as it minimizes configuration and processing overhead on the end-host and is widely supported by most Internet Protocol (IP) networks. As noted by the IETF, one of the drawbacks of using a statically configured default router is that it creates a single point of failure. Therefore, loss of the default router results in a catastrophic event, isolating all end-hosts that are unable to detect any alternate path that may be available. The use of standby routers, also referred to as redundant routers, eliminates the single point of failure inherent in the static default routed environment. (VRRP, Section 1, Introduction).
Protocols for using standby routers involve the notion of a virtual router. A virtual router is an abstract object managed by a standby router protocol (SRP), and it functions as a default router for end-hosts on a network. The virtual router is defined by a Virtual Router Identifier (VRID) and a set of associated IP addresses. The virtual router may be implemented with two or more routers running the SRP. The SRP specifies an election process whereby the responsibility for forwarding packets sent to the IP address(es) associated with the virtual router is dynamically assigned to one of the SRP routers, called the master. The remaining SRP routers are variously referred to as standby, backup, or slave routers, and are available to assume forwarding responsibility for a virtual router should the current master fail.
FIG. 1A is a block diagram that illustrates a typical prior art network configuration using the IETF VRRP. As illustrated, routers R1 110 and R2 120 are defined as VRRP routers connected to a virtual local area network VLAN1 115 supporting virtual routers VRID1 and VRID2. VRID1 is defined as the virtual router associated with IP subnet 10.2.3.1, and VRD2 is defined as the virtual router associated with IP subnet 10.2.4.1. Hosts H1 130 and H2 135 have configured a static default route through R1's IP address 10.2.3.1, and hosts H3 140 and H4 145 have configured a static default route through R2's IP address 10.2.4.1. R1 110 is the initial master for VRID1 and R2 120 is the backup (slave) router. Likewise, R2 is the initial master for VRID2 and R1 is the backup (slave) router. Thus, if R1 110 fails such as when the R1 ISP 150 connection 111 to the Internet 155 goes down, then R2 120 is elected the new master VRRP router for VRID1, and publishes the new subnet route 10.2.4.1 for hosts H1 130 and H2 135. Likewise, if R2 120 fails (e.g. the connection 121 to the Internet 155 goes down), then R1 110 is elected the new master VRRP router for VRID2, and publishes the new subnet route 10.2.3.1 for hosts H3 140 and H4 145. The election of the new master VRRP router is performed in accordance with the election process defined for the IETF VRRP protocol.
One of the drawbacks to implementing an SRP is that the SRP messaging that is necessary to support the election process generates a significant amount of network traffic. SRP messaging is performed using Internet Protocol (IP) multicast datagrams, specifically referred to as SRP packet datagram units (PDUs). Each end-host, subnet or any layer-2 domain participating in the SRP must send a PDU containing information about their status to the two or more routers running the SRP. If a large number of end-hosts, subnets, or layer-2 domains participate, the result is a periodic flooding of the network with SRP PDUs to and from the SRP routers.
FIG. 1B is a block diagram that illustrates a typical prior art network configuration similar to that illustrated in FIG. 1A, but with 200 VLANs 160, 161, 162, and 163 participating in the VRRP instead of a single VLAN1 115. Because the router R1 110 and R2 120 must exchange PDUs for all 200 VLANs over connection 115, the network can be overwhelmed. Nonetheless, all 200 VLANs must participate in the SRP in order to provide the benefits of dynamic failover that is critical to the support of a high level of uninterrupted service on a network. In some cases, it may be necessary to support thousands of VLANs or other layer-2 domains. It would be desirable, therefore, to devise a way to increase participation in an SRP without a concomitant increase in the amount of network traffic due to SRP messaging in order to provide scalability when implementing the SRP.
Another problem when implementing an SRP is that host-specific ports on the SRP routers running the SRP (i.e. the routers comprising the virtual router), are not utilized in a typical SRP routing configuration. Host-specific ports are generally used by a single end-host for which the port is specifically configured.
FIG. 1C is a block diagram that illustrates a typical prior art network configuration similar to that illustrated in FIG. 1B. In addition to the ports that support the 200 VLANs 160, 161, 162, and 163 that participate in the VRRP, routers R1 110 and R2 120 include host-specific ports that support end-host H5 112 and end-host H6 122, respectively. Because routers R1 and R2 are the end-hosts' only connection to the rest of the network and the Internet, R1 and R2 are still a single point of failure for those end-hosts. As a result, when used at all, these host-specific ports end up being relegated to less critical end-hosts where the need for redundancy is not as imperative. It would be desirable, therefore, to devise a way to allow these under-utilized ports to participate in SRP.